Preliminary Performance Evaluation of SandiaXTP on ATM at ORL

9 movement towards total CPU usage is diierent. In particular, there appears to be a sharp increase in CPU usage when the send buuer size becomes equal to the network buuer size. This occurs for both reliable and unreliable transmission. We have no rm explanation for this and investigations are continuing. Figure 5 shows the results for 4Kbyte network buuer sizes, the results are similar although the CPU usage is generally lower. This apparent mismatch between transmitters and receivers highlights the need to have proper qos support such as those in XTP to prevent receivers being swamped by one or more transmitters. Conclusions Some of the observations above are due to how the XTP protocol is implemented in SandiaXTP rather than the protocol itself. For large blocks, good throughput is achieved, while low throughput and high latency have been found for small blocks. In terms of multimedia, it is necessary to address this issue since audio uses relatively small blocks and has very strict temporal requirements. The results show that SandiaXTP would only support a small number of high quality audio channels. There has been some discussion about doing a kernel version of the SandiaXTP code for Unix systems. We believe that this will be useful and would probably increase performance. However, in the ATMos environment, where the core system is made up of a set of processes rather than a monolithic entity, we believe that there may be greater beneet in trying to run most or all of the XTP protocol in the process space of the application. This can be done by using threads and implementing the protocol as a user space library. We would also like to explore issues of Application Layer Framing (ALF) and Integrated Layer Processing (ILP) Clark90] in this context. We are presently examining these issues.